[BUGFIX] Re-check the composer.json url after every redirect - #306

)

The composer.json url is assembled by string substitution from webhook
payload fields, and the allowlist guarding it compares the **host
only**. A `#` or a `?` inside one of those fields therefore pushes the
intended `…/composer.json` suffix out of the path, and what actually
gets fetched is an arbitrary endpoint on an allowed host.

All four services produce a url whose path ends in `/composer.json`, so
requiring that suffix rejects those shapes while leaving every real url
untouched.

**What this does not fix:** the allowlist still stores a bare hostname,
so a different **port** on an allowed host is still reachable — this
only bounds what can be retrieved there to files named `composer.json`.
Making it exact depends on what the existing `KnownRepositoryDomain`
rows look like in production, which I cannot see.

`t3g:test` (169 tests), `t3g:phpstan` and `t3g:cgl` pass. Found while
working on #305, independent of it.

<details>
<summary>Details — evidence, bypass attempts, one risk to check, merge
notes</summary>

### Evidence

Built through the real `GitRepositoryService` with `project.web_url` as
the attacker-controlled field:

| payload value | path actually requested |
|---|---|
| `https://allowed.example/internal/admin#` | `/internal/admin` |
| `https://allowed.example/api/v4/user?a=` | `/api/v4/user` |
| `https://allowed.example:9200/_cluster/health#` | `/_cluster/health`
on port 9200 |

In each case the allowlist saw only `allowed.example` and passed. With
this change all three are rejected.

### Bypass attempts

I tried to get past the new check with percent-encoded slashes and dots
(`%2Fcomposer.json`, `composer%2Ejson`), uppercase, a semicolon
parameter, a trailing traversal after the suffix, and double slashes.
All rejected. What still passes is a traversal that itself ends in
`/composer.json` — consistent with the stated bound above.

### One risk worth checking

`publicComposerJsonUrl` is editable in the manual deployment wizard. If
any existing row points at a file not named `composer.json`, it would
now be rejected. A quick look at that column would confirm whether that
is the case.

### Exception handling

The new rejection uses `InvalidComposerJsonUrlException`, which no
caller handled — on its own that would answer a public request with a
500. This PR therefore also handles it, with its own history status
`INVALID_COMPOSER_JSON_URL` rather than reusing the one for an unknown
domain. That block is byte-identical to the one in #306, so the two
merge in either order.

### Merge notes

All three related PRs merge onto `develop` cleanly in any order —
verified by performing the merges, with an identical resulting tree, the
catch block and the status each present exactly once, and a green
combined suite.

</details>

Signed-off-by: Sebastian Mendel <github@sebastianmendel.de>

A quarantined rendering recorded the host of the **clone url**, while
the check that blocked it keys on the host of the **composer.json url**.
For GitHub those never match — `github.com` versus
`raw.githubusercontent.com`.

That is not cosmetic: approving an entry allowlists exactly the recorded
domain and replays every entry sharing it. So an admin approving a
GitHub repository creates a `KnownRepositoryDomain` for a domain the
fetch check never consults, while the replayed events are checked
against the real host and land in quarantine again. The approval
silently does nothing.

This records the host the check actually rejected. `updateLastHit()` had
the same mismatch and could never find the row it meant to touch.

**Needs a migration:** the feature shipped in 7.2.0, so existing rows
carry the wrong host and approving one of them reproduces the bug. The
migration recomputes the domain from the push event each row already
stores.

`t3g:test` (162 tests), `t3g:phpstan` and `t3g:cgl` pass. Found while
working on #305, independent of it.

<details>
<summary>Details — migration behaviour, the replay fix, tests, merge
notes</summary>

### Migration

The domain is recomputed from `serialized_push_event`, which contains
`urlToComposerFile`. Rows whose payload cannot be decoded are skipped
rather than failing the migration; rows already correct (Bitbucket
Cloud, most GitLab setups) are left alone. The checksum hashes only the
serialized push event and does not include the domain, so deduplication
is unaffected. It is irreversible — the old value came from a different
url and cannot be reconstructed.

I ran it against a SQLite database seeded with a GitHub row, a Bitbucket
row and a row with an undecodable payload: only the GitHub row changed,
from `github.com` to `raw.githubusercontent.com`.

### Replay loop made robust

Approving a domain replays every entry it holds. Until now a single
entry that cannot be rendered — an irrelevant branch name is the likely
case — threw out of the loop, gave the admin a 500, aborted the
remaining entries and left the queue half-processed. This was invisible
before, because the loop never got that far. Such an entry is now
skipped and the admin is told how many were dropped. Both approval paths
are covered.

### Tests

`RenderDocumentationServiceTest` pins that the host handed to
`quarantine()` and to `updateLastHit()` is the composer host, using a
GitHub-shaped push event where the two differ. I verified it
discriminates by reverting each production line separately — the test
fails each time. The earlier version of this PR only asserted a setter
passthrough, which stayed green when the real bug was restored; that gap
is what this test closes.

### Merge notes

#306 touches `RenderDocumentationService` in the same area. All three
related PRs merge onto `develop` cleanly in any order — verified by
performing the merges, with an identical resulting tree and a green
combined suite.

</details>

Signed-off-by: Sebastian Mendel <github@sebastianmendel.de>
Co-authored-by: Andreas Kienast <andreas.kienast@typo3.com>